FAQ
Part 5/7 • 22.6 KB total
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
What’s to stop someone from flooding the network?
As a routed network, a packet sent to a single destination would go through a single path and likely jam a single router. Sending packets to multiple other destinations would cause issues for local routers, but the larger network would be less affected as paths diverge. This is generally true of all routed networks, and proper interface settings and network topology can assist in a single router’s overload not affecting the wider network.
There is a conceptual threat behind using announces, which are propagated using rules closer to that of standard flood routing, but there are systems in place to mitigate this.
First, announces have a bandwidth cap. No matter the number of announces pending, a router will use the bulk of its bandwidth for transmitting messages, not announces.
Second, announce flood triggers special logic that prevents unknown destinations from broadcasting large numbers of announces, allowing known-good destinations to continue unimpeded operation and queuing any suspicious announces until they can be rebroadcast at a reasonable rate after the burst has concluded.
Third, individual servers can limit announce rates of all destinations, preventing a destination from announcing far more frequently than is useful.
There is also burst control in place for path requests.
What’s to stop someone from flooding the radio to prevent communication?
Nothing. This is a matter for local authorities, be it law enforcement or the private owner of the band. Electronic warfare is a major discipline and solutions to this issue are of international interest. That being said, radio direction-finding is a mature technology and RF power drops off quickly, so leading enforcement to a jammer is somewhat trivial; it’s like finding what light bulb was left on.
What are the system requirements for running a Reticulum node?
Most systems that can run Python 3 can run RNS without issues. Some systems may require manual compilation of the crypto libraries or a less secure pure-Python implementation.
Through experimentation, a major node can run on a single core in the GHz class with about 780 MB of RAM. This includes file transfer and other capability, but this is application specific, as Reticulum can load a file and transfer it, requiring the file be loaded into RAM, or stream it directly with a much lower overhead. At time of writing, major nodes are running on a 2 GB VM, a Pi 4, and a 2 GB Le Potato.
Improvements since version 0.9.5 of Reticulum has significantly improved memory consumption for both the core stack and Reticulum-based applications, and as an example, a major node handling more than 300 interfaces, and an average of 1000 active links at any given time currently uses about 250 MB of RAM. An LXMF propagation node with 50 connected peers, handling around 2 million messages per month will use around 280 MB of RAM.
The C++ port microReticulum allows constrained hardware like microcontrollers and single-board computers to become standalone Reticulum nodes. It can also produce binaries that run on Linux/macOS.
RNode